As is known, and referring now to FIG. 1, a rights management (RM) and enforcement system is highly desirable in connection with digital content 12 such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content 12 is to be distributed to users. Upon being received by the user, such user renders or ‘plays’ the digital content with the aid of an appropriate rendering device such as a media player on a personal computer 14, a portable playback device or the like.
Typically, a content owner distributing such digital content 12 wishes to restrict what the user can do with such distributed digital content 12. For example, the content owner may wish to restrict the user from copying and re-distributing such content 12 to a second user, or may wish to allow distributed digital content 12 to be played only a limited number of times, only for a certain total time, only on a certain type of machine, only on a certain type of media player, only by a certain type of user, etc.
However, after distribution has occurred, such content owner has very little if any control over the digital content 12. An RM system 10, then, allows the controlled rendering or playing of arbitrary forms of digital content 12, where such control is flexible and definable by the content owner of such digital content. Typically, content 12 is distributed to the user in the form of a package 13 by way of any appropriate distribution channel. The digital content package 13 as distributed may include the digital content 12 encrypted with a symmetric encryption/decryption key (KD), (i.e., (KD(CONTENT))), as well as other information identifying the content, how to acquire a license for such content, etc.
The trust-based RM system 10 allows an owner of digital content 12 to specify rules that must be satisfied before such digital content 12 is allowed to be rendered. Such rules can include the aforementioned requirements and/or others, and may be embodied within a digital license 16 that the user/user's computing device 14 (hereinafter, such terms are interchangeable unless circumstances require otherwise) must obtain from the content owner or an agent thereof, or such rules may already be attached to the content 12. Such license 16 may for example include the decryption key (KD) for decrypting the digital content 12, perhaps encrypted according to another key decryptable by the user's computing device or other playback device. Because the content 12 can only be rendered in accordance with the rules in the license 16, then, the content 12 may be freely distributed.
The content owner for a piece of digital content 12 would prefer not to distribute the content 12 to the user unless such owner can trust that the user will abide by the rules specified by such content owner in the license 16 or elsewhere. Preferably, then, the user's computing device 14 or other playback device is provided with a trusted component or mechanism 18 that will not render the digital content 12 except according to such rules.
The trusted component 18 typically has an evaluator 20 that reviews the rules, and determines based on the reviewed rules whether the requesting user has the right to render the requested digital content 12 in the manner sought, among other things. As should be understood, the evaluator 20 is trusted in the DRM system 10 to carry out the wishes of the owner of the digital content 12 according to the rules, and the user should not be able to easily alter such trusted component 18 and/or the evaluator 20 for any purpose, nefarious or otherwise.
As should be understood, the rules for rendering the content 12 can specify whether the user has rights to so render based on any of several factors, including who the user is, where the user is located, what type of computing device 14 or other playback device the user is using, what rendering application is calling the RM system 10, the date, the time, etc. In addition, the rules may limit rendering to a pre-determined number of plays, or pre-determined play time, for example.
The rules may be specified according to any appropriate language and syntax. For example, the language may simply specify attributes and values that must be satisfied (DATE must be later than X, e.g.), or may require the performance of functions according to a specified script (IF DATE greater than X, THEN DO . . . , e.g.).
Upon the evaluator 20 determining that the user satisfies the rules, the digital content 12 can then be rendered. In particular, to render the content 12, the decryption key (KD) is obtained from a pre-defined source and is applied to (KD(CONTENT)) from the content package 13 to result in the actual content 12, and the actual content 12 is then in fact rendered.
Oftentimes, the RM system 10 extends from the computing device 14 to one or more RM servers 22 that provide information, elements, and services in connection with the trusted component 18 and other RM elements on the computing device 14. For example, the trusted component 18 itself may be obtained from one such RM server 22, while licenses 16 may be obtained from another RM server 22, and content 12 may be protected with the aid of another RM server 22. Moreover, such one or more RM servers 22 may be employed to enroll users and/or computing devices 14 into the RM system 10, perhaps by way of issuance of a certificate or the like, or may be employed to give certain users special publishing rights, again perhaps by way of issuance of a certificate or the like.
Further, and as seen in FIG. 1, each RM server 22 that interfaces with a computing device 14 of a user may in turn interface with another RM server 22, perhaps to be enrolled into the RM system 10 once again perhaps by way of issuance of a certificate or the like. In short, it is to be appreciated that a veritable constellation of RM servers 22 can be employed in the RM system 10 to effectuate functions for such RM system 10 including those set forth above and others. An example of an RM system 10 employing such RM servers 22 is set forth in U.S. patent application Ser. Nos. 10/185,527, 10/185,278, and 10/185,511, each filed Jun. 28, 2002 and incorporated by reference in its entirety.
In general, and as should be appreciated, each RM server 22 in operation receives a request from a client such as a trusted component 18 on a computing device 14, another RM server 22, or the like, and in response to the request performs a task and then returns a result to the requesting client. Of course, the client request can vary from RM server 22 to RM server 22, or can be one of multiple types of client request directed to and handled by a particular RM server 22, or the like. As was alluded to above, and as should also be appreciated, typical tasks performed by an RM server 22 in response to a client request can include but are not limited to licensing, certification, activation, enrollment, publishing, and the like.
The task corresponding to any particular client request can and likely does have multiple task components. For example, a client request for a license 16 could result in a licensing task with components including parsing, request validation, policy validation, directory cross-referencing, business logic, billing, subscription maintenance, surveillance, logging, and the like. Significantly, such task components can be divided into core task components that must be completed before a decision is made on whether to honor the request, and peripheral task components that can be completed after a decision is made on whether to honor the request. For example, and with regard to the aforementioned client request for a license 16, parsing, request validation, policy validation, directory cross-referencing, and business logic could be core components of such request, and billing, subscription maintenance, surveillance, and logging could be peripheral components of such request.
In the context of an especially active environment, it can be the case that an engaged RM server 22 having to respond to multiple requests cannot do so in a reasonable period of time due to the number of corresponding task components that must be performed and/or the amount of time necessary to perform such task components. Likewise, in the context of any environment active or inactive, it can be the case that an engaged RM server 22 having to respond to a single request likewise cannot do so in a reasonable period of time due to the number of corresponding task components that must be performed and/or the amount of time necessary to perform such task components.
Accordingly, a need exists for an architecture and method that allows an RM server 22 to perform core task components relating to a request in a synchronous manner and to adjourn peripheral task components relating to the request to be performed elsewhere in an asynchronous manner. More particular, a need exists for such an architecture and method that allows the RM server 22 to perform the core task components prior to responding to the request and to pass the peripheral task components to one or more queues to be taken up prior to or after the request has been responded to as circumstances allow.